Hardware authentication tokens are typically implemented as small, hand-held devices that display a series of tokencodes over time. A user equipped with such a hardware authentication token reads the currently displayed tokencode and enters it into a mobile telephone, computer or other element of an authentication system as part of an authentication operation. It is also known to incorporate software authentication tokens in mobile telephones, computers or other user devices. The dynamic tokencodes provided by hardware or software authentication tokens offer a significant security improvement over authentication based on a static password.
Authentication tokens are typically provisioned with a random seed or other type of secret key that is also stored in a token record file of the authentication system. The token record file is loaded into an authentication server, such that the server can create matching tokencodes for the authentication token based on the secret key and the current time or current event count. When the user first activates the token, the server stores a personal identification number (PIN) for the user in association with the secret key corresponding to the activated token.
Conventional authentication tokens include both time-synchronous and event-synchronous tokens.
In a typical time-synchronous token, the displayed tokencodes are based on the secret key and the time of day. An authentication server with access to the secret key and a time of day clock can verify that a given presented tokencode is valid.
One particular example of a time-synchronous authentication token is the RSA SecurID® user authentication token, commercially available from RSA, The Security Division of EMC Corporation, of Bedford, Mass., U.S.A. Software versions of this exemplary time-synchronous authentication token, commonly referred to as RSA SecurID® software authenticators, are also commercially available.
Event-synchronous tokens generate tokencodes in response to a designated event, such as a user pressing a button on the token. Each time the button is pressed, a new tokencode is generated based on the secret key and an event counter. An authentication server with access to the secret key and the current event count can verify that a given presented tokencode is valid.
Other known types of authentication tokens include hybrid time-synchronous and event-synchronous tokens.
Many authentication systems are configured to require that a user enter the PIN in addition to entering the tokencode from the authentication token. This provides an additional security factor, based on something the user knows, thereby protecting against unauthorized use of an authentication token that is lost or stolen. Such an arrangement is generally referred to as two-factor authentication, in that authentication is based on something the user has (e.g., the authentication token) as well as something the user knows (e.g., the PIN).
In order to gain access to a protected resource, the user typically enters the PIN into a user device and the current tokencode displayed on his or her authentication token is also entered or otherwise obtained by the user device. The protected resource receives this information from the user device and passes it on to the authentication server, or the user device may provide the information directly to the authentication server. The authentication server will then check if the provided PIN and tokencode information matches the information it has for the user in its token record file in order to authenticate the user. If the user is successfully authenticated by the authentication server, access to the protected resource is granted, and otherwise access to the protected resource is denied.
A number of issues can arise when initially provisioning certain types of authentication tokens with their respective secret keys. For example, such provisioning in the context of configuring a mobile telephone, computer or other user device to implement certain types of software authentication tokens can be an unduly burdensome process for the user, possibly requiring manual help desk support. In addition, communication channels utilized in conjunction with this initial provisioning may in some cases lack adequate security protections and therefore can be vulnerable to a variety of different types of attacks, including man-in-the-middle attacks.